Flexible-Date Travel Queries

ABSTRACT

Techniques for processing flexible-date queries are described. Techniques include a interface to enter a flexible date query including a description of a traveler&#39;s desired stay at a destination. A user receives a set of solutions that satisfy the flexible date query in the form of a calendar. The set of solutions can be stored in a database for eventual retrieval of a subset of the set of solutions to render to a user.

BACKGROUND

This invention relates to travel scheduling and pricing, and moreparticularly to processing queries for air travel planning systems.

In travel planning such as for air travel scheduling and pricing,low-fare-search queries are posed by users from travel agent systems,airline reservation agent systems, travel web sites, andairline-specific web sites. Low-fare-search (LFS) queries typicallyinclude origin and destination information, time constraints andadditional information including passenger profile and travelpreferences. Travel planning computer systems respond to these LFSqueries and typically return a list of possible tickets, each havingflight and price information. Some systems return answers in a compactform such as through a pricing graph.

Most travel planning systems require each input LFS query to specify anarrow range of possible travel dates, e.g., one-day range, such as“depart anytime on August 2”, or perhaps a slightly longer range, suchas “return on either August 9 or 10.” Most systems do not permit querieswith more flexibility in their travel dates such as a query, “departanytime in August.”

Some travel websites such as Travelocity® and Expedia®, provide a typeof flexible-date query in the form of a “fare calendar.” The farecalendar technique requires a user to select one fare (for example, theUnited Airlines BOS-LAX fare with basis code QE14NR). The site willdisplay a calendar indicating the available travel dates for flightsusing that particular fare.

SUMMARY

There are several difficulties with handling “flexible travel date”queries. One difficulty is that the lack of precise date constraintsimposes extensive computational requirements on the search engineanswering the query. An airfare search can involve many flightcombinations and correspondingly availability questions, fares, andrules to process. Another difficulty resides in a user interface. Theuser interface should allow users to easily pose queries that matchtheir schedule's flexibility. In addition, the user interface shouldpresent query results in an informative and understandable manner.Another problem is that fare calendar technique, which requires the userto select a fare, is basically a trial-and-error approach makes the useof flexible date queries very time consuming and cumbersome for theuser.

According to an aspect of the invention, an interface for travelplanning includes a field that allows a user to enter a layoverdescription that includes the duration of the layover at a destination.

According to an additional aspect of the invention, a method ofprocessing flexible-date queries includes sending a flexible date queryincluding a description of a traveler's desired layover at adestination, receiving a set of solutions that satisfy the flexible datequery from executing the query using a search engine, and storing theset of solutions in a database. The method also includes retrieving asubset of the set of solutions to render to a user.

According to an additional aspect of the invention, an interface fortravel planning includes a depiction of a calendar that represents incells of the calendar search results for which a solution is found byusing information pertaining to a complete, validated solution in eachcalendar cell for which a solution was generated.

According to an additional aspect of the invention, a computer programproduct residing on a computer readable medium for processingflexible-date queries includes instructions to cause a processor to senda flexible date query including a description of a traveler's desiredlayover at a destination, receive a set of solutions that satisfy theflexible date query and store the set of solutions in a database. Thecomputer program product also includes instructions to retrieve a subsetof the set of solutions to render to a user.

Unlike prior approaches to handle flexible date queries the presenttechniques avoid a long trial-and-error process of investigating faresand looking for a fare that provides availability on preferred dates.This present technique provides the possibility of using farecombinations (e.g., BOS-CHI plus CHI-LAX) or multiple airlines, eitherof which might result in a cheaper price than any available single fare.

The techniques provide a query form that allows users to specify aflexible range of outbound and return dates for their travel plans,using a specification of their preferred layover length. The techniquestores results in a database for later retrieval and display. Resultsare conveyed to a user by use of a “results calendar” which displays anoverview of the solutions on a calendar. On days for which results havebeen requested, information such as that day's cheapest available ticketprice will be shown in the corresponding grid cell of the calendar. Theinformation displayed in each grid cell of the calendar corresponds toproperties of complete travel solutions, for which all rules andoptionally availability have been checked, and for which a ticket can beissued. No trial-and-error on the part of the user is required.

Users can interact with the results calendar in a number of ways. Forexample, the user can use filters to select or deselect travel oncertain airlines, travel involving one or more stops, etc., resulting inan update of the prices displayed in the calendar cells. The resultcalendar provides the ability to click on the price associated with agiven day, and quickly see an overview of flight choices on that day, aswell as a sampling of full, validated ticket options. Also the resultscalendar provides the ability to extend the query dates beyond thoseoriginally specified by clicking directly on the calendar. Specialparameter settings can be used to control the performance of theunderlying fare search engine.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a travel planning arrangement.

FIG. 2 is a interface form for flexible date queries.

FIG. 3 is a block diagram depicting actions in an initial query.

FIG. 4 is a diagram depicting a results calendar.

FIG. 5 is a diagram depicting a results interface.

FIGS. 6 and 7 are flow diagrams depicting alternative ways to producedata for the results interface.

FIG. 8 is a diagram depicting the results interface usinguser-selectable filters.

FIG. 9 is a block diagram depicting a travel planning system using splitqueries.

DETAILED DESCRIPTION

Referring to FIG. 1, an arrangement 10 for travel planning includes aprocess 12 to process flexible-date queries. A user such as a traveler,travel agent or airline reservation agent enters trip informationtypically including date and airport (i.e. origin and destination)information from a client system 14 into a travel application 16. Theclient 14 can run a browser or other interface and can be a travel agentterminal, an Internet web browser connected to a travel web site, and soforth. Queries 18 from the client are fed via a network 15 to the travelapplication. Network 15 can be any type of network such as a publicnetwork such as the Internet or telephone system or a private networksuch as a local area network (LAN), wide area network (WAN), virtualprivate network (VPN), and so forth. The travel application 16 typicallyresides on a web server 17. To process flexible-date queries, the travelapplication 16 allows a wide range of travel dates to be specified.

The travel application 16 interprets queries 18 that arrive from theclient 14, sends the queries 18 to a travel planning computer 20 and,organizes the results from the travel computer 20 into a formattedoutput such as HTML, and sends the results back to the client 14. Thetravel application 16 composes query information into an appropriatelyformatted query, e.g., a low-fare-search query 18, which is sent to atravel planning system 20. The travel planning system 20 includes asearch engine or search process 21 that searches for flight and farecombinations that satisfy the flexible date query. The search performedby the search engine 21 in the travel planning systems 20 can use any ofseveral know techniques, possible modified to include a query splittingprocess described below in FIG. 9.

Referring to FIG. 2, a graphical user interface 40 that is generated bythe travel application 16 controls interface, query specification,search engine parameter settings, results database management, andresults presentation for processing travel queries. In oneimplementation, the GUI 40 has separate panes for processing one-way(pane 41 a), round-trip (pane 41 b), multi-segment (pane 41 c), flexibledestination (pane 41 d), and flexible-date (pane 41 d) queries.

The travel application 16 controls the input specification for thequery. One approach would be to request four dates to be input by theuser: earliest possible departure date, latest possible departure date,earliest possible return date, and latest possible return date. However,this approach would result in a number of trip combinations proportionalto the product of the outbound date range and the return date range. Inmany circumstances where there are large values in those ranges thecomputation needed could overburden the search engine. For example, auser who proposed departing “anytime in July” and returning “anytime inAugust”, assuming 100 flight combinations per day serving the user'srequested airports, would translate into a search request of31*100*31*100 or nearly ten million flight combinations.

In practice a travelers' trips are constrained in duration, even if theyare flexible in departure date. Practical queries of this type resemblethe following:

“visit Daytona Beach for about a week sometime this winter”

“visit Burlington for a short weekend in October”-

“go to Chicago for a day trip some day next week”

“get a one-way ticket to San Francisco anytime this month”

In each of these examples, while the range of possible travel dates isquite wide, the duration or length of time spent at the destination isspecified with some precision. Accordingly, the graphical user interface40 pane 41 e for providing flexible-date queries includes a field 42where users specify the approximate duration of the trip. Users mayoptionally enter an outbound date range. The GUI 40 can also include afield for entering an earliest departure date (not shown) and a fieldfor entering a Latest departure date 43. The fields for entering anearliest departure date and latest departure date are optional fields.If an outbound range is not entered a default outbound date range can beused. One such default is “departing anytime between tomorrow and onemonth from today.”

The user specifies the desired duration in one of a number of mannersthat can be accessed via a scroll bar on the field 44. The forms oflayover length include “a day trip”, “weekend trip”, “month-long trip”,and so forth. This specification is selected from a menu or entered in atext field. The GUI 40 also includes a origin field 46 and a destinationfield 48, each of which allows inclusion of additional airports with auser specified number of miles from the origin or destination. The GUIcan also have fields 49 for specifying profile information, e.g., numberof adults, seniors, youths, children, infants (in seat or lap). A “Go”button launches the query and sends it to the travel application 16 fortransmission to the travel planning system 20.

The duration specification may include additional constraints beyond thelength of the stay. For example, a layover specification of “oneweekend” could be interpreted to mean a layover of duration 1 or 2nights, departing only on a Friday or Saturday. A layover specificationof “one-day business trip” could be interpreted to mean a same-dayreturn, departing only on a non-holiday weekday. Each additionalconstraint reduces the computational burden on the search engine,increasing the number of answers that can be generated within a givensearch time. Furthermore, the additional constraints make it easier forthe user to find a useful ticket option among the results presented. TheGUI can also include user specific choices for layover length, e.g.,under advanced options such as “one-way ticket only”, “one-day businesstrip”, “two-day business trip”, “one weekend”, “one long weekend”,“weekend to weekend”, “about one week”, “about two weeks”, “about threeweeks”, “about one month”, and so forth (not shown).

With the layover length specified, the computational burden on thesearch engine is significantly reduced. For example, if a user proposeddeparting “anytime in July” and returning after a layover of “about onemonth”, assuming a range of 29-31 days for the layover and againassuming 100 flight combinations per day, the number of flightcombinations in the search request would be 31*100*3*100—less than amillion, for a tenfold savings over the approach mentioned above.

Referring now to FIG. 3, the travel application 16 includes a process 60for handling flexible date queries. The process 60 sends 62 aflexible-date query to a search engine 21 (See also FIG. 1) via webserver 17. In response to receiving the flexible date query, the searchengine 21 produces a list of many (perhaps hundreds or thousands)solutions. Each solution comprises a combination of flights satisfyingthe user's requested parameters (airports, passengers, preferredairline, etc.), within the requested date range and the length of stay.Moreover, each flight combination is matched with a set of fares, andthose fares have been validated by checking all fare rules and seatavailability, with taxes also having been applied. Hence, associatedwith each solution is a price representing the complete price of theticket, ready for immediate booking. The set of solutions is stored 66in a database on disk 63. The database 63 can be a collection offormatted text files stored in a flat file system. Other implementationssuch as transactional databases could also be used. The solutions arestored in the database 63, which serves as the data source for displayand manipulation of a results calendar. The search engine 21 informs 64the web server 17 that solutions have been written.

The travel application 16 queries the database 63 to retrieve 68 the“best” solution given a current set of user-specified filters, for eachdeparture date. By default, the notion of “best” is defined simply asthe cheapest among all solutions computed and which are not filtered outby user specified criteria. Other definitions for “best” can be defined,often based on the initial query parameters specified by the user. Forexample, if the user specified that only first class service solutionswere desired, then “best” might be defined as the cheapest first-classsolutions, rather than the cheapest solutions in any class of service.

The travel application 16 has a calendar generator 65 that generates 70a results calendar, highlighting properties of the best solution(s)corresponding to each departure date, and sends 72 the results calendarto the user. The user may select or modify filters (for example, tofilter out solutions involving particular airlines or solutionsinvolving prop planes). The process 60 returns to retrieve (again 68)another set of best solutions, by retrieving from its database only thesubset of solutions matching the new filter criteria. The user mayaugment the query (again 62), either by requesting additional solutionsfor a date that has already been considered, or by asking the system toextend the permissible date range to new dates. In either case thesystem writes (again 66) newly discovered solutions to the solution setstored in the database 63. The search engine 21 informs (again 64) theweb server 17 that solutions have been written.

The solutions are stored in the database 63 for the duration of a user'ssession with the website. However, an extension could provide for thedatabase 63 to be maintained across multiple users' sessions. Thisextension would involve inserting an additional action at the beginningprocess, e.g., the travel application checks database to see whethersolutions to the user's query have already been stored; if so, thenretrieve best solutions without having the search engine perform anothersearch.

Because airline fares and seat availability change frequently, solutionsare either pruned from the database 63 within a few hours of theirhaving been generated, or refreshed by a follow-up query to the searchengine 1, so as to avoid presenting solutions on the “results calendar”display that cannot be booked. The system could also regularly posequeries to the search engine (e.g., during times of excess search-enginecapacity) for the purpose of “stocking” the database with up-to-datesolution sets in commonly traveled markets.

The Results Calendar

Potentially, hundreds or thousands of travel solutions, spanning manydifferent departure dates, are stored in the database 63. The system 10(FIG. 1) summarizes these travel solutions in a manner that the end usercan comprehend. The summary is presented as a calendar spanning allmonths covered by the solution set. In a calendar grid cellcorresponding to each day on which a set of valid solutions depart, theprocess provides one or more properties of the solution set. Theseproperties may include one or more of the following:

The price of the best solution departing on that day, where “best”refers to the cheapest ticket meeting the user's cabin-class preferenceand other filters;

The primary airline(s) used by the best solutions departing on that day(represented by the airline's name, icon, or two-letter code);

The number of stops in the best solution departing on that day; and

An indication of the cabin class, origin and departure airports andtimes, and equipment type (for example, an icon of a propeller to denotea prop plane) associated with the best solution departing on that day.

Referring to FIG. 4, an illustration of the calendar with results isshown. In this interface, one price 82 is displayed on each calendar dayfor which results have been computed. Each price is underlined to showthat it is a hypertext link 83. Clicking on the link 83 brings upanother web page 85 (FIG. 5).

As illustrated in FIG. 5, the web page 85 displays the results for asingle day. The web page 85 provides two types of information: thedetails of the particular solution(s) that generated the price shown;and an overview of the other options available on that day, which mayinvolve different routings, different carriers, different departuretimes, different layover lengths, and so forth. The web page 85 includesa table 87 that summarizes the travel options for a single solution setand day. The travel option summary table 87 has multiple tabs, e.g., atab 87 a that groups summary information by airlines and number of stopsand a tab 87 b that groups summary information by flight times. A tab(not shown) can be included to summarize travel information by airports.Other tabs can be used to summarize other travel information accordingto other criteria such as class of service, safety of equipment, etc.

With the airline tab 87 a selected, the summary information in the table87 is arranged in rows and columns with here enumerating the airlinesthat offer solutions for the date selected arranged in columns of thetable as links, and each of the rows of the table 87 arranging specifiedtravel options such as nonstop flights or one-stop flights, and so forthas links. Interior cells within the table 87 are links that correspondto prices for the solutions that match the user's airline and number ofstops criteria. The table 87 displays a set of air travel optionsaccording to specified criteria, e.g., the airlines used in one or moreof the travel options (displayed horizontally at the top of the table),and the number of stops or connections in the set of travel options(displayed vertically on the left of the table). Here, the traveloptions represented by a given table cell are those solutions which usethe airline in the same column as that cell, and that have the samenumber of stops as the “number of stops” header in the same row as thatcell. A third criteria, price (i.e. price of an airline ticket), isdisplayed in each cell of the table; this price is the minimum price forany of the travel solutions that are represented by a given cell.

Selecting a cell (by clicking on a URL in this case) displays, in alower pane 89, a listing of the travel solutions for that particularcell. Each travel solution contains a ‘details’ URL link in the row ofinformation devoted to that travel solution. Clicking on that link takesthe user to a detailed description of that travel solution (not shown).

A general procedure to construct the summarizing tabs 87 a and 87 b isgiven below:

1) Obtain list of query-specific travel solutions from database.

2) For each criteria in travel solutions:

-   -   Enumerate bins for the criteria    -   For each travel solution T:        -   Place travel solution T into some bin

3) Given the bins computed in (2), compute which travel solutions gointo intersecting bin pairs to determine what travel solutions go inwhat cells of the summary table.

4) Generate and display summary table given information from procedure(3).

When the flight time tab 87 b is selected, the table 87 is arranged toshow departure times between the origin and the destination over rangesof times for the potential days of travel in the outbound portion of thetrip in rows of the table, as well as departure time for the returnportion of the trip in columns of the table 87 over time ranges in thepotential return days. Thus, selecting one of the outer peripheral cellsof the table will bring up all flight options on a designated day in thedesignated time area; whereas selecting an interior one of the cellswill produce the intersection of solutions for a time segment on theselected outbound date and the time segment of the selected return date.Each solutions table 87 cell displays the cost of the cheapest solutionsfor each pair of intersecting time segments, allowing a user to decidethe most appropriate time to travel giving consideration such as costand convenience.

Several approaches can be used to produce data for inclusion in thecalendar results web pages.

Referring now to FIG. 6, an approach 90 that can be used to produce datafor inclusion in the web page is shown. The approach 90 uses theoriginal flexible-date query solution set. When the user clicks on thelink associated with a given departure date on the calendar (FIG. 4 or5), the travel application filters its current working solution set bydeparture date to generate the subset of solutions for that day. Thelink that the user clicks on is sent 92 to the web server 17. The webserver 17 sends 94 a corresponding request to the calendar resultsdisplay generator 66. The generator 66 issues a request 96 a to thedatabase 63 that holds the results of the original flexible-data querysolution set. The database 63 returns 96 b the subset of solutions forthat day to the calendar results display generator 65. This subset issent 97 to the web server and is used to generate the result page. A newcalendar display is produced 98 and sent to the client system 14 whereit is displayed. The advantage of this method is that it requires nofurther work from the search engine when the user selects a calendar daylink. The disadvantage is that, given the limited computation timeavailable to handle the original flexible date query, the subset ofresults on each day may not be diverse enough to populate the overviewtable fully.

The search engine parameters can be set so as to increase the diversityof solutions generated by the search engine. This helps ensure that eachcell of the overview table is represented by at least one solution oneach departure date. However, recognizing that many additional solutionsare missing from the initially generated set, the interface provides aprominent link labeled, e.g., “Search for additional options likethese.” This link is similar to the follow-up query as discussed in FIG.7 below; it submits a new query to the search engine in order togenerate additional solutions departing on the date in which the userhas expressed particular interest. The newly generated solutions areadded to the solutions database for subsequent interactions.

Referring to FIG. 7, another approach 100 to produce data for inclusionin the web page uses a follow-up query that is posed to the searchengine. When the user clicks 102 on the link associated with a givendeparture date on the calendar, the travel application, via the webserver 17 poses 104 a follow-up query to the search engine 21. Thisfollow-up query constrains the search to departures on the particulardate chosen, which gives the search engine 21 time to generate moreflight combinations. The expanded solution set is used to populate theoverview table 87 (FIG. 5). The link that the user clicks on is sent 102to the web server 21. The web server 21 determines 104 if a full set ofsolutions have already been produced for this date; yes, the web serversends 106 a corresponding request to the calendar results displaygenerator 65. The generator 65 issues 108 a request to the database 63that holds the results of the query solution set. The database returns110 the subset of solutions for that day to the calendar. The calendargenerator 65 generates the appropriate calendar from the solution setand this subset is sent to the web server, which is sent 112 for displayat the client system.

However, if the full set of solutions has not been completed the webserver sends 114 a request for a single day query to the search engine.The search engine produces a diverse list of travel options according toa set of travel criteria such as carrier, departure or arrival times,time of day, origin, destination, airports and so forth. A diversityprocess can iterate through a set of travel criteria and select the besttravel option for each criterion. When the search engine has determineda complete set of solutions, the search engine informs 116 the webserver 21. The results are written 118 to the database 63 for use by thecalendar generator 65 as just mentioned above.

It frequently occurs that the cheapest trip satisfying the user's queryon some or all dates within the user's date range has some propertiesundesirable to the user. For example, the cheapest solution on some orall dates might be available only on “Undesirable Airlines”, or mightinvolve an inconvenient number of connections en route to thedestination. If the prices displayed on the calendar correspond only tothese undesirable solutions, the calendar is less valuable to the user.

FIG. 8 discussed below is a different configuration of the resultscalendar interface shown in FIG. 4. In FIG. 8, clicking on a price linkin one of the calendar cells displays the results for the clicked-on dayto the right of the calendars, rather than bringing up a new web pagewith just the results for the clicked-on day. This is useful for userswho have computer monitors large enough to accommodate both thecalendars and the single-day information on the screen at the same time.

Referring to FIG. 8, one implementation of the results window 85provides user-selectable filters 130 of the solution set. FIG. 8 andFIG. 4 (discussed above) include filters (to filter out airlines). Thefilters 130 may be used individually or in combination. When a filter130 is selected, then the properties shown in each date cell of thecalendar are updated so as to reflect the best solution for that datewhich passes all the selected filters. For example, the user may electto filter out any solution that involves either “undesirable” airlinesor solutions which contain two or more connections en route to thedestination. Having made those selections, the user would likely observesome of the prices shown on the calendar to increase, reflecting theelimination of the undesirable solutions from the solution set. In FIG.8, the user has clicked on the price in the calendar cell for June 8(which can be indicated by a highlight not shown), which displays theflight options for June 8 on the right. The user also clicks on thecarrier filter “SY” to filter out flights on that carrier.

The following is a partial list of criteria that may be applied asfilters on the calendar's solution set:

-   -   airlines (any subset of airlines may be selected or deselected);    -   number of connections in the solution (e.g., nonstop, single        connection, etc.)    -   cabin class (first, business, refundable coach, economy coach)    -   layover duration (filter by length of stay)    -   origin and destination airports (applies in cases where        alternative airport choices were given in the query, e.g.,        LGA/JFK/EWR).    -   equipment types (e.g. propeller planes)    -   overnight flights and other undesirable departure times    -   awkward connections such as a long stopover at an intermediate        city    -   en-route change of airport    -   outbound and return departure times (e.g., morning, midday,        afternoon, evening)    -   airline safety and on-time performance records.

The filters can be implemented as an advanced options link on theresults page that can bring up another page (not shown) to allow usersto input their preferences for these items.

When calendar filters are selected, the same filters are simultaneouslyapplied to the single-day result page currently being displayed. In thatway, the price highlighted on any given date of the calendar alwayscorresponds to the cheapest price on that day's corresponding single-dayresult page.

Referring back to FIG. 6, as discussed earlier, the set of departuredates considered in a flexible-date query may be restricted by theuser-entered earliest and latest departure dates, as well as by thelayover specification. For example, if a user requests a trip departingbetween February 1 and 28, with a “long weekend” layover, then thesystem will produce results for only a handful of days, e.g., Thursdaysand Fridays in February. Thus, the calendar of results will show priceson that set of dates only. Upon seeing those results, the user maynaturally want to extend the set of possible travel dates to includeadditional dates. The interface can provide various types ofquery-extending links.

For example, on dates for which the calendar shows no associatedsolutions, links are provided that cause a follow-up query to be posedto the search engine, filling the gap on that date. A second type ofextending link would be that on the column headings of each calendar,corresponding to the weekdays of that month, a link is provided thatcauses all weekdays in that month to be added to the dates underconsideration. When that link is followed, any dates not already filledin are resubmitted to the search engine, filling any gaps on thatweekday. A third type would be on the row headings of each calendar,corresponding to a given departure week, a link provides for anautomatic follow-up query to the search engine to fill in the emptycells corresponding to days during that week. In addition, links can beprovided to enable the user to add an additional month's calendar,immediately prior to or subsequent to the displayed calendar(s). When anew month is added, all dates on that month are shown as blankinitially, with links provided as in (1)-(3) above to fill in the blankdates. Alternatively, the system may submit a follow-up query to fillpart or all of the newly displayed month with solutions.

The departure date information of the query is modified when the queryis resubmitted. All other query fields, such as the passengerinformation, airport preferences, and layover specification, arepreserved. As before, the newly generated solutions are added to thesolutions database for subsequent interactions.

Search Engine Parameters for Flexible-Date Queries

Although using a layover specification helps to constrain the amount ofsearching that the search engine performs, flexible-date queries stillinvolve searching many more flight options than a standard, single-dayquery. As such, the flexible date queries are likely to require morecomputation time. Several techniques can be used to limit the search,while not compromising the ability of the system to generate useful,fully validated solutions.

One such technique would be to limit the search according toflight-itinerary diversity. In normal, single-day operation, a searchengine may consider as many as 1000 of the most convenient flightcombinations between the user's origin and destination. To handleflexible-date queries quickly, this number is reduced to a few dozen perday, representing only the most convenient options on a sampling ofcarriers.

Another solution would be to limit the search according to seatavailability. When there are multiple flight-combinations on a given dayon a given airline, the one with the cheapest price is usually the onewith the most seat availability. The system checks the seat availabilityon all flight-combination options and prunes out those with lower seatavailability. The result is that the search space shrinks, while thebest answer for each airline on each date is most likely preserved. Athird possibility is to limit the search by fare. Airlines typicallypublish dozens, and sometimes as many as hundreds, of different faresfor each city-pair that they serve. Significant reduction incomputations can be attained by eliminating some of these fares fromconsideration—for example, all first-class and business-class fares.

Another way would be to limit the search by construction. On anitinerary such as United:BOS-CHI-LAX, it is usually possible to fare theitinerary either as a BOS-LAX “through fare”, or as the sum of a“BOS-CHI” fare and a “CHI-LAX” fare. Eliminating the latter faring, andrequiring only through fares to be used in the search would result insignificant reductions in computations.

An additional technique would be to limit the search by priceable unittype. Airline fare construction principles require all tickets to bebroken down into sub-units called priceable units, of which there arefour types: one-way, round-trip, open-jaw, and circle-trip. Open jaw andcircle-trip units sometimes result in the cheapest solution even on asimple round-trip journey, but usually one-way and round-trippriceable-units suffice. The faring process can be sped up byeliminating open-jaw and circle-trip priceable units from consideration.

Another technique to reduce latency of low fare searching uses querysplitting. Query splitting involves dividing the query among severaldifferent processors in a “farm” of low-fare search engines, asdiscussed in FIG. 9 below.

Referring to FIG. 9, in some embodiments of the travel planning system20, the travel planning system includes a query distributor 22 thatalters the query 18 to produce sub-queries 18 a-18 i that aredistributed to various travel planning computers 20 a-20 n, where n doesnot necessarily equal i. The travel planning computers 20 a-20 n executethe sub-queries 18 a-18 i concurrently to produce answers 24 a-24 i. Theanswers 24 a-24 i to these sub-queries 18 a-18 i are sent back to theuser, via the web server 17. In one embodiment, the answers 24 a-24 iare sent to an answer collator 25, which merges the answers 24 a-24 iinto a composite answer 26 and sends that answer 26 to the web server 17for transmission to the client 14. The travel planning system includes asearch engine or process 21 that is run on each of the travel planningcomputers 20 a-20 n.

The answers for each sub-query may be collected and organized by theanswer collator 25 using a number of different techniques. If the formof the sub-query results is a simple list of travel options, thecollation process used by the answer collator 25 may simply involveconcatenating the answers from each sub-query. However more complexcollations schemes are possible, such as selecting a subset of answersfrom each sub-query (such as the cheapest travel options from amongstall of the answers and so forth). Alternatively, if the query divisionprocess 12 produces sub-queries that overlap, the collation process 25could remove duplicate answers. In the case where the travel planningcomputers produce answers in other forms, such as a pricing graphrepresentation, other methods of collation may be used. For example,multiple pricing graphs can be merged into one by joining them with anOR node. It may also be that no collation process is used, so thatanswers for the different sub-queries are returned to the travelapplication as soon as they are available, rather than waiting for allsub-queries to complete.

When queries are split using this technique, the user-interface candisplay the results on the calendar progressively, as the sub-queriesfinish and results are returned using dynamically generated animated-GIFimages and image maps.

Algorithms for performing such query splitting are described inco-pending patent application Ser. No. ______ Filed ______ Entitled“Split Travel Queries” by assigned to the assignee of the presentinvention.

A number of embodiments of the invention have been described.Nevertheless, it will be understood that various modifications may bemade without departing from the spirit and scope of the invention.Accordingly, other embodiments are within the scope of the followingclaims.

1. An interface for travel planning comprises: a field that allows auser to enter a layover description that include the duration of thelayover at a destination.
 2. The interface of claim 1 wherein thelayover description may imply other constraints on the departure date.3. The interface of claim 1 wherein the constraint is leaving on onlycertain days of the week.
 4. The interface of claim 1 wherein theinterface is a graphical user interface that is divided into a pluralityof panes, with one of the plurality of panes corresponding to a flexibledate query form to enter flexible date queries, with the destinationfield being on the form.
 5. The interface of claim 4 wherein the panecorresponding to the flexible date query form to enter flexible datequeries further includes a field to enter an earliest departure date. 6.The interface of claim 4 wherein the pane corresponding to the flexibledate query form to enter flexible date queries further includes a fieldto enter an origin and a field to enter a destination.
 7. A method ofprocessing flexible-date queries comprises sending a flexible date queryincluding a description of a traveler's desired layover at adestination; receiving a set of solutions that satisfy the flexible datequery from executing the query using a search engine; storing the set ofsolutions in a database; and retrieving a subset of the set of solutionsto render to a user.
 8. The method of claim 7 wherein the databasestores the solution set according to departure date.
 9. The method ofclaim 7 further comprising: augmenting the database with additionalresults from follow-up queries posted by user.
 10. The method of claim 7further comprising: rendering results to the user as a calendar having alink in a cell representing a property of at least one solution foundfor a day corresponding to the cell, with the link when selectedrendering additional details of the at least one solution found for thatday.
 11. The method of claim 7 further comprising: augmenting thedatabase with solutions for commonly traveled markets and layoverlengths using an offline process that runs periodically.
 12. The methodof claim 7 further comprising: filtering the solution set according touser specified parameters.
 13. The method of claim 7 further comprising:filtering the solution set to allow the user to select a particularairline or set of airlines, causing the calendar's prices to be updatedso as to reflect the complete price of the cheapest ticket originatingon each day using only the selected airline or airlines.
 14. The methodof claim 10 further comprising: searching the set of solutions resultingfrom the flexible date query to generate the subset of solutions for theday when a user selects a link.
 15. The method of claim 10 furthercomprising: providing a follow-up query to the search engine to producedata for inclusion in the subset of solutions, in response to the userselecting the link associated with a given departure date on thecalendar.
 16. An interface for travel planning comprises: a depiction ofa calendar that represents in cells of the calendar search results forwhich a solution is found by using information pertaining to a complete,validated solution in each calendar cell for which a solution wasgenerated.
 17. The interface of claim 16 wherein the informationdisplayed in a day's grid cell is a price.
 18. The interface of claim 16wherein the information displayed in a day's grid cell is a pricecorresponding to the complete price of the cheapest ticket originatingon that day.
 19. The interface of claim 16 further comprising: fields toallow a user to filter the solution set to allow the user to select aparticular airline or set of airlines, causing the calendar's prices tobe updated so as to reflect the complete price of the cheapest ticketoriginating on each day using only the selected airline(s).
 20. Theinterface of claim 16 further comprising; fields that provide filters tofilter the solution set according to at least one of number ofconnections in the solution, cabin class, layover duration, equipmenttypes, origins, and destinations, so that the calendar's prices displaythe cheapest ticket using the selected one or ones of the filters. 21.The interface of claim 16 wherein the information displayed in a day'sgrid cell is information displayed as a hypertext link.
 22. Theinterface of claim 16 wherein following the hypertext link produces asummary of the validated ticket options departing on that day.
 23. Theinterface of claim 22 wherein the summary is depicted as a list ofsolutions.
 24. The interface of claim 22 wherein the summary is depictedas an overview table of solutions grouped by carrier and other solutionproperties.
 25. The interface of claim 22 wherein the summary reflectsany filters selected by the user.
 26. The interface of claim 22 whereinon dates for which the calendar has produced no associated solutions,links are provided to allow a follow-up query to be posed to the searchengine to produce solutions on that date.
 27. The interface of claim 22wherein links are provided on columns and rows of the calendar,corresponding to weekdays and weeks respectively, allow a range of datesto be added to the query pool.
 28. The interface of claim 22 wherein theinterface includes a variety of parameter settings that can reduce thework performed by the search engine to minimize the computational burdenincurred by a flexible date query.
 29. A computer program productresiding on a computer readable medium for processing flexible-datequeries comprises instructions to cause a processor to: send a flexibledate query including a description of a traveler's desired layover at adestination; receive a set of solutions that satisfy the flexible datequery; store the set of solutions in a database; and retrieve a subsetof the set of solutions to render to a user.
 30. The computer programproduct of claim 29 wherein instructions to store, store the solutionset according to departure date.
 31. The computer program product ofclaim 29 further comprising instructions to: render results to the useras a calendar having a link in a cell representing a property of atleast one solution found for a day corresponding to the cell, with thelink when selected rendering additional details of the at least onesolution found for that day.
 32. The computer program product of claim29 further comprising instructions to: filter the solution set accordingto user specified parameters.
 33. The computer program product of claim29 further comprising instructions to: filter the solution set to allowthe user to select a particular airline or set of airlines, causing thecalendar's prices to be updated so as to reflect the complete price ofthe cheapest ticket originating on each day using only the selectedairline or airlines.
 34. The computer program product of claim 31further comprising instructions to: provide the subset of solutions tothe user when the user clicks on a link associated with a givendeparture date on the calendar by instructions to: search the set ofsolution resulting from the flexible date query to generate the subsetof solutions for the day corresponding to the link.
 35. The computerprogram product of claim 31 further comprising instructions to: providea follow-up query to the search engine to produce data for inclusion inthe subset of solutions, in response to the user selecting the linkassociated with a given departure date on the calendar.